Proper Workflow
To unlock the full potential of a Git repository, branch management and a structured workflow is key. Whether working on a solo project or a large collaborative project, branch management is the difference between being able to roll back changes and easily incorporate new features and having to manually reconstruct an entire project after a simple mistake is made. While branch management paradigms are largely based on personal preference there are some simple rules and guidelines one can follow as a beginner or to acquire a more specific taste. Simple Branch Diagram The image on the right demonstrates an implementation of a structured branch management paradigm. Commits are represented by circles and merges are represented by arrows. The initial repository commit is shown in the top right corner in the master branch. Note that even this simple structure includes many branches. Using many branches allows each branch to have a singular purpose and organize commits. This paradigm allows a team of developers to easily keep track of changes to the repository and allows for some flexibility. Main Branches The simplest paradigm for version control is commonly referred to as a master-develop structure. The master branch is reserved for finalized program versions, and the develop branch is where new changes are made. By separating finalized version, the repository can be rolled back to a stable version if needed. Additionally, a developer can automatically reference a singular branch to automatically update distributed software following the release of a new stable version. Master The master branch is the default branch for all Git repositories. Because of this, it is commonly used for final versions of a program. These final versions are often called releases. Note that these releases have been tagged with a version number such as 0.2 or 1.0. Commits are only made to the master branch when a new release is ready. Note as well that only the release and hotfix branches are allowed to merge into the master branch. Develop The develop branch is where the common branch for a repository. This branch is always kept as the most up to date branch. It is where new features are integrated and where new releases begin. Most other branches will eventually merge into the develop branch, with the master branch being the exception. All new development, except that of large, planned features happens in the develop branch. Because this branch is very busy, when committing to this branch it is important to use descriptive commit messages and to commit cohesive updates. Supporting Branches While the master-develop structure works well for small-scale and solo projects, in a large collaborative project, it becomes more important to manage the develop branch. By creating specialized supporting branches, lead developers can manage the develop branch while delegating smaller task to other developers who can commit to the supporting branches. While providing more control over the busiest repository branch, commits are organized according to task as well as function. While many different supporting branch functions can be utilized there are several functions which are common to many different project structures. Feature A feature branch is created when work on a new planned or large-scale feature begins. It is important to separate these large features because it allows new stable release versions to be created without having to finalize development on all current new features. Additionally, incomplete or unwanted features can be easily discarded without making any changes to the develop branch. Typically a feature branch will include only a single or interrelated set of features. These branches may be remote branches accessible by a number of developers or local branches accessible by a single developer. These branches are always cloned from the most up to date develop branch and always merge back into that branch upon completion of the feature. Release A release branch is used to prepare for the next stable release. Once it is decided that work on a new release will begin, the develop branch is cloned into a a new release branch. This allows release preparation to be completed isolated from normal development on the develop branch. Commits made on the release branch are continually merged back into the develop branch to keep it up to date. Once work on the release is finalized, this branch is merged into the master branch and tagged with a new release number. Hotfix Hotfix branches are important for projects where development continues while previous release version are in use by the public. If a major bug is found in a release version of a program, the bug must be immediately dealt with to restore functionality to the program. A hotfix is a bug fix on a release, or hot, branch. Only changes directly related to fixing these bugs should be committed to the hotfix branch. After the bugs have been smashed, The changes are merged not only into a new release in the master branch but into the develop branch. This allows these fixes to be incorporated into both the next release and the most current development version.